Hi, |
Re: Updating DXL attributes in multiple modules |
Re: Updating DXL attributes in multiple modules rain_bow - Wed Jan 11 08:14:26 EST 2012 |
Re: Updating DXL attributes in multiple modules BillTidy - Wed Jan 11 08:42:40 EST 2012 |
Re: Updating DXL attributes in multiple modules SystemAdmin - Wed Jan 11 11:15:07 EST 2012
I emphasize the "If" in the 1st paragraph. In big organizations that's often not true, and someone who looks at the attr will get numerous rude DXL errors. To "push" attributes to many modules, manually update one such module, save it, move it to some folder (perhaps the Project folder), then use script "copyAtts.dxl", of which there are lots of versions out there. Then move the module back to its permanant location. This is a reason to have "Template" modules, of a few different types (Requiremetns, Tests...), keep those up to date and just push them around to keep all your module's attributes up to date. Having said that, I intend to do this: write a custom DXL that lists every module and every attribute and the file containing that attributes Attr-DXL, then run that on-demand script to update all my project's Attr-DXL. The main reason is because I'm now writing "context sensitive" Attr-DXL that looks at the current attribute name to determine what exactly what to do. Script "Interface_Summary.dxl" displays different sorts of summaries depending on the name of the attribute e.g. "InterfaceAttrs", "SourceAttrs", "DestinationAttrs" bla bla bla. I may have 20 Attr-DXL in a module and don't want to even do one such template module manually. I'm considering another approach, some module-level attribute lists the attr-DXL names and the source DXL file name, and the script reads that and updates this module accordingly. These let me have my cake and eat it too, and single repository of managed DXL available to lots of folks who may not have access to that server folder. -Louie Actually, since I'm a dweeb, I've proved the concept of "deploying" the code in the database in configuration files, and the Attr-DXL reads the config file, eval_ and display the results. That's too slow but the concept will work for Addins menu problems with distributed clients. The database admins determine which addins are appropriate for their database. |
Re: Updating DXL attributes in multiple modules llandale - Wed Jan 11 14:43:43 EST 2012
I emphasize the "If" in the 1st paragraph. In big organizations that's often not true, and someone who looks at the attr will get numerous rude DXL errors. To "push" attributes to many modules, manually update one such module, save it, move it to some folder (perhaps the Project folder), then use script "copyAtts.dxl", of which there are lots of versions out there. Then move the module back to its permanant location. This is a reason to have "Template" modules, of a few different types (Requiremetns, Tests...), keep those up to date and just push them around to keep all your module's attributes up to date. Having said that, I intend to do this: write a custom DXL that lists every module and every attribute and the file containing that attributes Attr-DXL, then run that on-demand script to update all my project's Attr-DXL. The main reason is because I'm now writing "context sensitive" Attr-DXL that looks at the current attribute name to determine what exactly what to do. Script "Interface_Summary.dxl" displays different sorts of summaries depending on the name of the attribute e.g. "InterfaceAttrs", "SourceAttrs", "DestinationAttrs" bla bla bla. I may have 20 Attr-DXL in a module and don't want to even do one such template module manually. I'm considering another approach, some module-level attribute lists the attr-DXL names and the source DXL file name, and the script reads that and updates this module accordingly. These let me have my cake and eat it too, and single repository of managed DXL available to lots of folks who may not have access to that server folder. -Louie Actually, since I'm a dweeb, I've proved the concept of "deploying" the code in the database in configuration files, and the Attr-DXL reads the config file, eval_ and display the results. That's too slow but the concept will work for Addins menu problems with distributed clients. The database admins determine which addins are appropriate for their database. You can find attached a script (zip) called "findAndReplaceDXLAttributesInProject.dxl" that allows to find DXL attributes that contain a certain string or find and replace the string with another string. The function scans a folder and all its subfolders. Another DXL in the szip file contains a recursive function that scans a folder / project and calls a callback function. Feel free to use it. You can of course check the code and give me youf feedback. I have used it many times in my company and has been very helpful. Best regards, Alain Attachments attachment_14782971_findAndReplaceInDXLAttributes.zip |
Re: Updating DXL attributes in multiple modules adevicq - Fri Jan 27 08:50:45 EST 2012 Very good idea. These three lines starting at line #85
Probably doesn't matter, but I'd change the for loop starting at line #58 to this:
I notice you only change one occurance of the string; ignoring any others. The contains(string) function looks for "keywords", and will not find "aint" in "taint". Since you are likely looking for whole word phrases that doesn't matter, in this case. Please provide an example of when you would want to replace a phrase (only) in all such DXL. I'm thinking of stealing this DXL, and modifying it such that it looks for a particular string in the DXL, and if found replaces the entire code with some selected file. If I then put the name of the DXL in the dxl, perhaps "dxl_Display_Sections.dxl", then when I update that file I can replace all the attr-DXL that have that file in them. For me, I would restrict it to only look for that file name in the 1st line of the DXL since I always put it there. -Louie |
Re: Updating DXL attributes in multiple modules llandale - Fri Jan 27 10:40:57 EST 2012
Probably doesn't matter, but I'd change the for loop starting at line #58 to this:
I notice you only change one occurance of the string; ignoring any others. The contains(string) function looks for "keywords", and will not find "aint" in "taint". Since you are likely looking for whole word phrases that doesn't matter, in this case. Please provide an example of when you would want to replace a phrase (only) in all such DXL. I'm thinking of stealing this DXL, and modifying it such that it looks for a particular string in the DXL, and if found replaces the entire code with some selected file. If I then put the name of the DXL in the dxl, perhaps "dxl_Display_Sections.dxl", then when I update that file I can replace all the attr-DXL that have that file in them. For me, I would restrict it to only look for that file name in the 1st line of the DXL since I always put it there. -Louie I would see if the "modify" actually worked; look for the returned AttrDef or surround with noError()/lastError() Your dealWithFolder/Module schema is pretty clever. -Louie |
Re: Updating DXL attributes in multiple modules llandale - Fri Jan 27 10:48:04 EST 2012 Thanks for your comment. About concatenation instead of using "+=": I've had some issues with this in DXL (in some circumstances it seems it does not work so I abandoned it... maybe I'm wrong). About the checkDXL: in fact if the DXL is not valid it is impossible to save the module. So I left it like this as it is impossible to introduce a script that contains syntax errors... I wrote this script initially to change the location of include files generally located on a server but I have changed its organization or location a couple of times. therefore most of the time I had to change something like "//myserver/myfolder/.../" by "//myotherserver/myotherfolder/.../". In this case I have very few chances to replace something I'm not supposed to change! Feel free to enhance it as you wish (and of course share those changes on this forum!) Many thanks Alain |
Re: Updating DXL attributes in multiple modules adevicq - Fri Jan 27 11:00:38 EST 2012
"+=" is pretty standard and I haven't had trouble with it. For me the right side is always a string. if you can recall the trouble please let us know.
Buffer bufGlobal = create()
string DoSomething(()
{ bufGlobal = 1st line // <<-- This is the mindful step
bufGlobal += 2nd line
bufGlobal += 3rd line
return(stringOf(bufGlobal))
}
|
Re: Updating DXL attributes in multiple modules llandale - Fri Jan 27 13:32:38 EST 2012
"+=" is pretty standard and I haven't had trouble with it. For me the right side is always a string. if you can recall the trouble please let us know.
Buffer bufGlobal = create()
string DoSomething(()
{ bufGlobal = 1st line // <<-- This is the mindful step
bufGlobal += 2nd line
bufGlobal += 3rd line
return(stringOf(bufGlobal))
}
Louie, you keep saying that allocating a buffer is really slow. Just to see how slow, slow really is, I scribbled the below example. On my PC the appending of three strings to a buffer and doing stringOf is 1.5x - 2x slower than allocating and deleting a buffer (110ms vs. 187ms on DOORS 8.2). Of course it would be totally unnecessary to allocate the buffer in that function, so of course the global variable is the better option. I just wanted to point out that allocating a buffer and appending a string to a buffer nearly take the same time (at least when the allocation list is empty). Also note that both operations are very fast (90ms / 100000 = 900 ns) and most of the time it will be no improvement to the overall speed of the program to do so.
pragma runLim, 0
Buffer buf
int i, start
string a = "123456"
string b = "678909"
string c = "abcdef"
start = getTickCount_()
for (i = 0; i < 100000; i++) {
buf = create()
delete buf
}
print "Allocating and Deleting Buffer:" (getTickCount_() - start) "\n"
buf = create()
start = getTickCount_()
for (i = 0; i < 100000; i++) {
buf = a
buf += b
buf += c
stringOf buf
}
print "Appending Stuff To Buffer:" (getTickCount_() - start) "\n"
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
Re: Updating DXL attributes in multiple modules Mathias Mamsch - Sun Jan 29 06:32:00 EST 2012
Louie, you keep saying that allocating a buffer is really slow. Just to see how slow, slow really is, I scribbled the below example. On my PC the appending of three strings to a buffer and doing stringOf is 1.5x - 2x slower than allocating and deleting a buffer (110ms vs. 187ms on DOORS 8.2). Of course it would be totally unnecessary to allocate the buffer in that function, so of course the global variable is the better option. I just wanted to point out that allocating a buffer and appending a string to a buffer nearly take the same time (at least when the allocation list is empty). Also note that both operations are very fast (90ms / 100000 = 900 ns) and most of the time it will be no improvement to the overall speed of the program to do so.
pragma runLim, 0
Buffer buf
int i, start
string a = "123456"
string b = "678909"
string c = "abcdef"
start = getTickCount_()
for (i = 0; i < 100000; i++) {
buf = create()
delete buf
}
print "Allocating and Deleting Buffer:" (getTickCount_() - start) "\n"
buf = create()
start = getTickCount_()
for (i = 0; i < 100000; i++) {
buf = a
buf += b
buf += c
stringOf buf
}
print "Appending Stuff To Buffer:" (getTickCount_() - start) "\n"
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
"at least when the allocation list is empty"
pragma runLim, 0
Buffer buf
int i, start
string a = "123456"
string b = "678909"
string c = "abcdef"
//*****************************
void CreateKeepLotsBuffers()
{ start = getTickCount_()
for (i=0; i<1000; i++)
buf = create()
print "Allocating and lots: \t\t" (getTickCount_() - start) "\n"
}
//*****************************
void CreateDeleteBunchBuffers()
{ start = getTickCount_()
for (i = 0; i < 100000; i++) {
buf = create()
delete buf
}
print "Allocating and Deleting Buffer:\t" (getTickCount_() - start) "\n"
}
//*****************************
void GetTakeFromSingleBuffer()
{ buf = create()
start = getTickCount_()
for (i = 0; i < 100000; i++) {
buf = a
buf += b
buf += c
stringOf buf
}
print "Appending Stuff To Buffer:\t" (getTickCount_() - start) "\n"
delete(buf)
}
CreateDeleteBunchBuffers()
GetTakeFromSingleBuffer()
CreateKeepLotsBuffers()
CreateDeleteBunchBuffers()
GetTakeFromSingleBuffer()
Allocating and Deleting Buffer: 312 Appending Stuff To Buffer: 438 Allocating and lots: 0 Allocating and Deleting Buffer: 2047 Appending Stuff To Buffer: 437
Allocating and Deleting Buffer: 329 Appending Stuff To Buffer: 437 Allocating and lots: 22359 Allocating and Deleting Buffer: 346891 Appending Stuff To Buffer: 453
|